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Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
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Abstract 


The Internet Engineering Task Force (IETF) has responsibility for 
developing and reviewing specifications intended as Internet 
Standards. IETF activities are organized into working groups (WGs). 
This document describes the guidelines and procedures for formation 
and operation of IETF working groups. It describes the formal 
relationship between IETF participants WG and the Internet 
Engineering Steering Group (IESG). The basic duties of IETF 
participants, including WG Chair and IESG Area Directors are defined. 
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Iz INTRODUCTION 


This document defines guidelines and procedures for Internet 
Engineering Task Force working groups. The Internet is a loosely- 
organized international collaboration of autonomous, interconnected 
networks; it supports host-to-host communication through voluntary 
adherence to open protocols and procedures defined by Internet 
Standards, a collection of which are commonly known as "the TCP/IP 
protocol suite". The Internet Standards Process is defined in [1]. 
Development and review of potential Internet Standards from all 
sources is conducted by the Internet Engineering Task Force (IETF). 


The IETF is a large, open community of network designers, operators, 
vendors, users, and researchers concerned with the Internet and the 
technology used on it. The IETF is managed by its Internet 
Engineering Steering Group (IESG) whose membership includes an IETF 
Chair, responsible for oversight of general IETF operations, and Area 
Directors, each of whom is responsible for a set of IETF activities 
and working groups. The IETF Executive Director and IESG Secretary 
are ex-officio participants, as are the IAB Chair and a designated 
Internet Architecture Board (IAB) member. At present there are 10 
areas, though the number and purview of areas changes over time: 


User Services (USV) 
Applications (APP) 
Service Applications (SAP) 
Transport Services (TSV) 
Internet (INT) 
Routing (RTG) 
Network Management (MGT) 
Operational Requirements (OPS) 
Security (SEC) 
Standards & Processes (STD) 
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Most areas have an advisory group or directorate. The specific name 
and the details of the role for each group differs from area to area, 
but the primary intent is that the group assist the Area Director, 
e.g., with the review of specifications produced in the area. An 
advisory group is formed by an Area Director (AD) and comprises 
experienced members of the IETF and technical community represented 
by the area. A small IETF Secretariat provides staff and 
administrative support for the operation of the IETF. 


The primary activities of the IETF are performed by committees known 
as working groups. There are currently more than 60 of these. 
Working groups tend to have a narrow focus and a lifetime bounded by 
completion of a specific task, although there are exceptions. 


There is no formal membership in the IETF. Participation is open to 
all. This participation may be by on-line contribution, attendance 
at face-to-face sessions, or both. Anyone from the Internet 
community who has the time and interest is urged to participate in 
IETF meetings and any of its on-line working group discussions. 
Participation is by individual technical contributors, rather than by 
formal representatives of organizations. 


This document defines procedures and guidelines for formation and 
operation of working groups in the IETF. It defines the relations of 
working groups to other bodies within the IETF. The duties of working 
group Chairs and Area Directors with respect to the operation of the 


working group are also defined. The document uses: "Shall", "will", 
"must" and "is required" where it describes steps in the process that 
are essential, and uses: "suggested", "should" and "may" are where 


guidelines are described that are not essential, but are strongly 
recommended to help smooth WG operation. 


1.1. IETF approach to standardization 


The reader is encouraged to study The Internet Standards Process [1]. 
Familiarity with this document is essential for a complete 
understanding of the philosophy, procedures and guidelines described 
in this document. 


The goals of the process are summarized in [1]: 


"In general, an Internet Standard is a specification that is 
stable and well-understood, is technically competent, has 
multiple, independent, and interoperable implementations 
with operational experience, enjoys significant public 
support, and is recognizably useful in some or all parts of 
the Internet. 
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"In outline, the process of creating an Internet Standard is 
straightforward: a specification undergoes a period of 
development and several iterations of review by the Internet 
community and perhaps revision based upon experience, is 
adopted as a Standard by the appropriate body (see below), 
and is published. 


"In practice, the process is somewhat more complicated, due 
to (1) the number and type of possible sources for 


specifications; (2) the need to prepare and revise a 
specification in a manner that preserves the interests of 
all of the affected parties; (3) the importance of 


establishing widespread community agreement on its technical 
content; and (4) the difficulty of evaluating the utility of 
a particular specification for the Internet community. 


"These procedures are explicitly aimed at developing and 
adopting generally-accepted practices. Thus, a candidate 
for Internet standardization is implemented and tested for 
correct operation and interoperability by multiple, 
independent parties, and utilized in increasingly demanding 
environments, before it can be adopted as an Internet 
Standard." 


The IETF standardization process has been marked by informality. As 
the community of participation has grown it has become necessary to 
document procedures, while continuing to avoid unnecessary 
bureaucracy. This goals of this balancing act are summarized in [1] 
as: 


"The procedures that are described here provide a great deal 
of flexibility to adapt to the wide variety of circumstances 
that occur in the Internet standardization process. 
Experience has shown this flexibility to be vital in 
achieving the following goals for Internet standardization: 


high quality, 

prior implementation and testing, 
openness and fairness, and 
timeliness." 


+ + F 


1.2. Acknowledgments 
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Vaudreuil and Steve Coya who provided several paragraphs. Also, John 
Stewart and Steve Crocker did a truly stellar job of proof-reading. 
However, all the errors you'll find are probably ours. 


2. WORKING GROUP (WG) FORMATION 


IETF working groups (WGs) are the primary mechanism for development 
of IETF specifications and guidelines, many of which are intended as 
standards or recommendations. A working group may be established at 
the initiative of an Area Director (AD) or it may be initiated by an 
individual or group of individuals. Anyone interested in creating an 
IETF working group must obtain the advice and consent of the 
appropriate IETF Area Director under whose direction the working 
group would fall and must proceed through the formal steps detailed 
in this section. 


A working group is typically created to address a specific problem or 
produce a deliverable (a guideline, standards specification, etc.) 
and is expected to be short-lived in nature. Upon completion of its 
goals and achievement of its objectives, the working group as a unit 
is terminated. Alternatively at the discretion of the IESG, Area 
Director, the WG Chair and the WG participants, the objectives or 
assignment of the working group may be extended by enhancing or 
modifying the working group’s charter. 


2.1. Criteria for formation 


When determining whether it is appropriate to create a working group, 
the Area Director and the IESG will consider several issues: 


z Are the issues that the working group plans to address clear 
and relevant for the Internet community? 


- Are the goals specific and reasonably achievable, and 
achievable within the time frame specified by the 
milestones? 


= What are the risks and urgency of the work, to determine the 
level of attention required? 


= Do the working group's activities overlap with those of 
another working group? If so, it may still be appropriate to 
create the working group, but this question must be 
considered carefully by the Area Directors as subdividing 
efforts often dilutes the available technical expertise. 
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= Is there sufficient interest and expertise in the working 
group’s topic with at least several people willing to expend 
the effort to produce the desired result (e.g., a protocol 
specification)? Working groups require considerable effort, 
including management of the working group process, editing 
of working group documents, and contribution to the document 
text. IETF experience suggests that these roles typically 
cannot all be handled by one person; four or five active 
participants are typically required. 


- Does a base of interested consumers (end users) appear to 
exist for the planned work? Consumer interest can be 
measured by participation of end-users within the IETF 
process, as well as by less direct means. 


Considering the above criteria, the Area Director will decide whether 
to pursue the formation of the group through the chartering process. 


2.2. Charter 


The formation of a working group requires a charter which is 
primarily negotiated between a prospective working group Chair and 
the relevant Area Director, although final approval is made by the 
TESG and all charters are reviewed by the Internet Architecture Board 
(IAB). A charter is a contract between a working group and the IETF 
to perform a set of tasks. A charter: 


Ti: Lists relevant administrative aspects of the working group; 
Zt Specifies the direction or objectives of the working group 
and describes the approach that will be taken to achieve the 


goals; and 


3 Enumerates a set of milestones together with time frames for 
their completion. 


When the prospective Chair, the Area Director and the IESG Secretary 
are satisfied with the charter form and content, it becomes the basis 
for forming a working group. The AD may require an initial draft of a 
charter to be available prior to holding an exploratory Birds of a 
Feather (BOF) meeting, as described below. 


Charters may be renegotiated periodically to reflect the current 
status, organization or goals of the working group. Hence, a charter 
is a contract between the IETF and the working group which is 
committing to meet explicit milestones and delivering concrete 
"products". 
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Specifically, each charter consists of 6 sections: 
Working group name 


A working group name should be reasonably descriptive or 
identifiable. Additionally, the group shall define an 
acronym (maximum 8 printable ASCII characters) to reference 
the group in the IETF directories, mailing lists, and 
general documents. 


Chair (s) 
The working group may have one or two Chair(s) to perform 
the administrative functions of the group. The email 
address(es) of the Chair(s) shall be included. 
Area and Area Director(s) 
The name of the IETF area with which the working group is 
affiliated and the name and electronic mail address of the 
associated Area Director. 
Mailing list 
It is required that an IETF working group have a general 
Internet mailing list. Most of the work of an IETF working 
group will be conducted that. 
The charter shall include: 
The address to which a participant sends a 
subscription request and the procedures to follow when 


subscribing, 


The address to which a participant sends submissions 
and special procedures, if any, and 


The location of the mailing list archive, if any. 
A message archive should be maintained in a public place 
which can be accessed via FTP. The ability to retrieve from 
the archive via electronic mail requests also is 
recommended. Additionally, the address: 


ietf-archive@cnri.reston.va.us 


shall be included on the mailing list. 
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NOTE: It is strongly suggested that the mailing list be on 
a host directly connected to the IP Internet to facilitate 
use of the SMTP expansion command (EXPN) and to allow mail 
archive access via FTP, gopher and the like in keeping with 
the general IETF rule for openness. If this is not possible, 
the message archive and membership of the list must be made 
available to those who request it by sending a message to 
the list-request alias. 


Description of working group 


The focus and intent of the group shall be set forth briefly. By 
reading this section alone, an individual should be able to decide 
whether this group is relevant to their own work. The first paragraph 
must give a brief summary of the problem area, basis, goal(s) and 
approach(es) planned for the working group. This paragraph will 
frequently be used as an overview of the working group’s effort. 


The terms "they", "them" and "their" are used in this document as 
third-person singular pronouns. 


To facilitate evaluation of the intended work and to provide 
on-going guidance to the working group, the charter shall 
describe the problem being solved and shall discuss 
objectives and expected impact with respect to: 


= Architecture 

z Operations 

= Security 

= Network management 

- Transition (where applicable) 


Goals and milestones 


The working group charter must establish a timetable for 
work. While this may be re-negotiated over time, the list 
of milestones and dates facilitates the Area Director’s 
tracking of working group progress and status, and it is 
indispensable to potential participants identifying the 
critical moments for input. Milestones shall consist of 
deliverables that can be qualified as showing specific 
achievement; e.g., "Internet-Draft finished" is fine, but 
"discuss via email" is not. It is helpful to specify 
milestones for every 3-6 months, so that progress can be 
gauged easily. This milestone list is expected to be 
updated periodically. Updated milestones are re-negotiated 
with the Area Director and the IESG, as needed, and then are 
submitted to the IESG Secretary: 
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TESG-secretary@cnri.reston.va.us 
An example of a WG charter is in Appendix A. 
2.3. Charter review & approval 


Working groups often comprise technically competent participants who 
are not familiar with the history of Internet architecture or IETF 
processes. This can, unfortunately, lead to good working group 
consensus about a bad design. To facilitate working group efforts, 
an Area Director may assign an Area Consultant from among the ranks 


of senior IETF participants. (Area Consultants are described in the 
section of Staff Roles.) At the discretion of the AD, approval of a 
new WG may be withheld in the absence of sufficient Consultant 
resources. 


Once the Area Director (and the Area Directorate, as the AD deems 
appropriate) has approved the working group charter, the charter is 
submitted for review by the IAB and approval by the Internet 
Engineering Steering Group using the criteria described previously. 


The Internet Architecture Board (IAB) will review the charter of the 
proposed WG to determine the relationship of the proposed work to the 
overall architecture of the Internet Protocol Suite. 


The approved charter is submitted to the IESG Secretary who records 
and enters the information into the IETF tracking database and 
returns the charter in a form formatted by the database. The working 
group is announced to the IETF mailing list by the IESG Secretary. 


2.4. Birds of a feather (BOF) 


Often it is not clear whether an issue merits the formation of a 
working group. To facilitate exploration of the issues the IETF 
offers the possibility of a Birds of a Feather (BOF) session, as well 
as the early formation of an email list for preliminary discussion. 
Alternatively, a BOF may serve as a forum for a single presentation 
or discussion, without any intent to form a working group. 


A BOF is a session at an IETF meeting which permits "market research" 
and technical "brainstorming". Any individual may request permission 
to hold a BOF on a subject. The request must be filed with the 
relevant Area Director. The person who requests the BOF is usually 
appointed as Chair of the BOF. The Chair of the BOF is also 
responsible for providing a report on the outcome of the BOF. 
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The AD may require the conduct of email discussion, prior to 
authorizing a BOF. This permits initial exchanges and sharing of 
framework, vocabulary and approaches, in order to make the time spent 
in the BOF more productive. The AD may require that a BOF be held, 
prior to establishing a working group, and the AD may require that 
there be a draft of the WG charter prior to holding a BOF. 


Usually the outcome of a BOF will be one of the following: 


- There was enough interest and focus in the subject to 
warrant the formation of a WG; 


- The discussion came to a fruitful conclusion, with results 
to be written down and published, however there is no need 
to establish a WG; or 


T There was not enough interest in the subject to warrant the 
formation of a WG. 


There is an increasing demand for BOF sessions at IETF meetings. 
Therefore the following rules apply for BOFs: 


= All BOFs must have the approval of the appropriate Area 
Director. The Secretariat will NOT schedule or allocate time 
slots without the explicit approval of the Area Director. 


- The purpose of a BOF is to conduct a single, brief 
discussion or to ascertain interest and establish goals for 
a working group. All BOF organizers are required to submit a 
brief written report of what transpired during the BOF 
session together with a roster of attendees to the IESG 
Secretary for inclusion in the Proceedings. 


= A BOF may be held only once (ONE slot at one IETF Plenary 
meeting). 


- Under unusual circumstances an Area Director may, at their 
discretion, allow a BOF to meet for a second time. Typically 
(though not a requirement) this is to develop a charter to 
be submitted to the IESG. 


= BOFs are not permitted to meet three times. 
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3% 


3; 


I 


= A BOF may be held for single-event discussion, or may pursue 
creation of normal IETF working groups for on-going 
interactions and discussions. When the request for a BOF 
comes from a formally-constituted group, rather than from an 
individual, the rules governing the handling of the request 
are the same as for all other BOFs and working groups. 


- When necessary, WGs will be given priority for meeting space 
over BOFs. 


WORKING GROUP OPERATION 


The IETF has basic requirements for open and fair participation and 
for thorough consideration of technical alternatives. Within those 
constraints, working groups are autonomous and each determines most 
of the details of its own operation with respect to session 
participation, reaching closure, etc. The core rule for operation is 
that acceptance or agreement is achieved via working group "rough 
consensus". 


A number of procedural questions and issues will arise over time, and 
it is the function of the Working Group Chair to manage the group 
process, keeping in mind that the overall purpose of the group is to 
make progress towards reaching rough consensus in realizing the 
working group’s goals and objectives. 


There are few hard and fast rules on organizing or conducting working 
group activities, but a set of guidelines and practices have evolved 
over time that have proven successful. These are listed here, with 
actual choices typically determined by the working group participants 
and the Chair. 


Session planning 

For coordinated, structured WG interactions, the Chair must publish a 
draft agenda well in advance of the actual session. The agenda needs 
to contain at least: 

- The items for discussion; 

= The estimated time necessary per item; and 

A clear indication of what documents the participants will 


need to read before the session in order to be well 
prepared. 
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Publication shall include sending a copy to the working group mailing 
list and to the IETF-Announce list. Notices for the IETF-Announce 
list should be sent to: 


ietf-announce-post@cnri.reston.va.us 


All working group actions shall be taken in a public forum, and wide 
participation is encouraged. A working group will conduct much of 
its business via electronic mail distribution lists but may meet 
periodically to discuss and review task status and progress, to 
resolve specific issues and to direct future activities. It is 
common, but not required, that a working group will meet at the 
trimester IETF Plenary events. Additionally, interim sessions may be 
scheduled for telephone conference, video teleconference, or for 
face-to-face (physical) sessions. 


All working group sessions (including those held outside of the IETF 
meetings) shall be reported by making minutes available. These 
minutes should include the agenda for the session, an account of the 
discussion including any decisions made, and a list of attendees. The 
Working Group Chair is responsible for insuring that session minutes 
are written and distributed, though the actual task may be performed 
by someone designated by the Working Group Chair. The minutes shall 
be submitted in printable ASCII text for publication in the IETF 
Proceedings, and for posting in the IETF Directories and are to be 
sent to: 


minutes@cnri.reston.va.us 
3.2. Session venue 


Each working group will determine the balance of email and face-to- 
face sessions that is appropriate for achieving its milestones. 
Electronic mail permits the widest participation; face-to-face 
meetings often permit better focus and therefore can be more 
efficient for reaching a consensus among a core of the working group 
participants. In determining the balance, the WG must ensure that 
its process does not serve to exclude contribution by email-only 
participants. Also note that decisions reached during IETF meetings 
are NOT final, but must be conveyed to the mailing list to verify WG 
consensus. 


IETF Meetings 
If a WG needs a session at an IETF meeting, the Chair must apply for 
time-slots as soon as the first announcement of that IETF meeting is 


made by the IETF Secretariat to the WG-chairs list. Session time is 
a scarce resource at IETF meetings, so placing requests early will 
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facilitate schedule coordination for WGs requiring the same set of 
experts. 


The application for a WG session at an IETF meeting shall be made to 
the IETF Secretariat. Alternatively some Area Directors may want to 
coordinate WG sessions in their area and request that time slots be 
coordinated through them. After receiving all requests for time 
slots by WGs in the area, the Area Director(s) form a draft session- 
agenda for their area, which is then sent to the WG chairs of the 
area. After approval it will be sent to the IETF Secretariat. 


An application must contain: 
< The amount of time requested; 


= The rough outline of the WG agenda that is expected to be 
covered; 


- The estimated number of people that will attend the WG 
session; 


- Related WGs that must not be scheduled for the same time 
slot(s); and 


= Individuals whose attendance is desired. 


The Secretariat allots time slots on the basis of the session-agenda 
made by the Area Director(s). If the proposed session- agenda for an 
area does not fit into the IETF meeting-agenda, the IETF Secretariat 
will adjust it to fit, after consulting the Area Director(s) and the 


relevant chairs. The Secretariat will then form a draft session- 
agenda and distribute it among the Working Group Chairs for final 
approval. 


NOTE: While open discussion and contribution is essential to working 
group success, the Chair is responsible for ensuring forward 
progress. When acceptable to the WG, the Chair may call for 
restricted participation (but not restricted attendance!) at IETF 
working group sessions for the purpose of achieving progress. The 
Working Group Chair then has the authority to refuse to grant the 
floor to any individual who is unprepared or otherwise covering 
inappropriate material. 


On-line 
It can be quite useful to conduct email exchanges in the same manner 


as a face-to-face session, with published schedule and agenda, as 
well as on-going summarization and consensus polling. 
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Many working group participants hold that mailing list discussion is 
the best place to consider and resolve issues and make decisions. 
Choice of operational style is made by the working group itself. It 
is important to note, however, that Internet email discussion is 
possible for a much wider base of interested persons than is 
attendance at IETF meetings, due to the time and expense required to 
attend. 


3.3. Session management 


Working groups make decisions through a "rough consensus" process. 
IETF consensus does not require that all participants agree although 
this is, of course, preferred. In general the dominant view of the 
working group shall prevail. (However, it must be noted that 
"dominance" is not to be determined on the basis of volume or 
persistence, but rather a more general sense of agreement.) 

Consensus can be determined by balloting, humming, or any other means 
on which the WG agrees (by rough consensus, of course). 


The challenge to managing working group sessions is to balance the 
need for open and fair consideration of the issues against the need 
to make forward progress. The working group, as a whole, has the 
final responsibility for striking this balance. The Chair has the 
responsibility for overseeing the process but may delegate direct 
process management to a formally-designated Facilitator. 


It is occasionally appropriate to revisit a topic, to re-evaluate 
alternatives or to improve the group’s understanding of a relevant 
decision. However, unnecessary repeated discussions on issues can be 
avoided if the Chair makes sure that the main arguments in the 
discussion (and the outcome) are summarized and archived after a 
discussion has come to conclusion. It is also good practice to note 
important decisions/consensus reached by email in the minutes of the 
next ‘live’ session, and to summarize briefly the decision-making 
history in the final documents the WG produces. 


To facilitate making forward progress, a Working Group Chair may wish 
to direct a discussion to reject or defer the input from a member, 
based upon the following criteria: 


Old 


The input pertains to a topic that already has been resolved 
and is redundant with information previously available; 
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Minor 


The input is new and pertains to a topic that has already 
been resolved, but it is felt to be of minor import to the 
existing decision; 


Timing 
The input pertains to a topic that the working group has not 
yet opened for discussion; or 


Scope 


The input is outside of the scope of the working group 
charter. 


3.4. Contention and appeals overview 


In the course of group design processes, strife happens. Strife and 
contention are particularly likely when working groups comprise many 
constituencies. On the other hand differences in view are vital to 
the success of the IETF and healthy debate is encouraged. Sometimes 
debates degenerate into something akin to warfare. For these 
circumstances, the IETF has an extensive review and appeals process. 


Formal procedures for requesting review and conducting appeals are 
documented in The Internet Standards Process [1]. A brief summary is 
provided, here. 


In fact the IETF approach to reviews and appeals is quite simple: 
When an IETF participant feels that matters have not been conducted 
properly, they should state their concern to a member of IETF 
management. In other words, the process relies upon those who have 
concerns raising them. If the result is not satisfactory, there are 
several levels of appeal available, to ensure that review is possible 
by a number of people uninvolved in the matter in question. 


Reviews and appeals step through four levels, each in turn: 
WG Chair 
An appeal must begin with the management closest to the 


operation of the working group, even if the concern applies 
to their own handling of working group process. 
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Area 


If discussion and review with the WG Chair do not produce a 
satisfactory result, the complainant may bring their concern 
to the cognizant Area Director. 


IESG 


If a concerned party is not satisfied with the results of 
the area-level review, then they may bring the matter to the 
IESG Chair and the Area Director for Standards & Processes. 
The IESG Chair and the Standards & Processes AD will bring 
the issue before the full IESG for an additional review and 
will report the resolution back to the parties. 


IAB 


The IAB provides a final opportunity to appeal the results 
of previous reviews. If a concerned party does not accept 
the outcome of the IESG review, then they may take their 
concern to the IAB, by contacting the IAB Chair. 


Concerns entail either a disagreement with technical decisions by the 
working group or with the process by which working group business has 
been conducted. Technical disagreements may be about specific 
details or about basic approach. When an issue pertains to 
preference, it should be resolved within the working group. When a 
matter pertains to the technical adequacy of a decision, review is 
encouraged whenever the perceived deficiency is noted. For matters 
having to do with preference, working group rough consensus will 
dominate. 


When a matter pertains to working group process, it is important that 
those with a concern be clear about the manner in which the process 
was not open or fair and that they be willing to discuss the issue 
openly and directly. In turn, the IETF management will make every 
effort to understand how the process was conducted, what deficiencies 
were present (if any) and how the matter should be corrected. The 
IETF functions on the good will and mutual respect of its 
participants; continued success requires continued attention to 
working group process. 


4. WORKING GROUP TERMINATION 
Working groups are typically chartered to accomplish a specific task. 
After that task is complete, the group will be disbanded. However if 


a WG produces a Proposed or Draft Standard, the WG will become 
dormant rather than disband (i.e., the WG will no longer conduct 
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formal activities, but the mailing list will remain available to 
review the work as it moves to Draft Standard and Standard status.) 


If, at some point, it becomes evident that a working group is unable 
to complete the work outlined in the charter, the group, in 
consultation with its Area Director can either: 


ds Recharter to refocus on a smaller task, 
ake Choose new Chair(s), or 
St Disband. 


If the working group disagrees with the Area Director’s choice, it 
may appeal to the IESG. 


5. STAFF ROLES 


Working groups require considerable care and feeding. In addition to 
general participation, successful working groups benefit from the 
efforts of participants filling specific functional roles. 


5.1. WG Chair 


The Working Group Chair is concerned with making forward progress 
through a fair and open process, and has wide discretion in the 
conduct of WG business. The Chair must ensure that a number of tasks 
are performed, either directly or by others assigned to the tasks. 
This encompasses at the very least the following: 


Ensure WG process and content management 


The Chair has ultimate responsibility for ensuring that a 
working group achieves forward progress and meets its 
milestones. For some working groups, this can be 
accomplished by having the Chair perform all management- 
related activities. In other working groups -- particularly 
those with large or divisive participation -- it is helpful 
to allocate process and/or secretarial functions to other 
participants. Process management pertains strictly to the 
style of working group interaction and not to its content. 
It ensures fairness and detects redundancy. The secretarial 
function encompasses document editing. It is quite common 
for a working group to assign the task of specification 
Editor to one or two participants. Often, they also are 
part of the design team, described below. 
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Moderate the WG email list 


The Chair should attempt to ensure that the discussions on 
this list are relevant and that they converge to consensus 
agreements. The Chair should make sure that discussions on 
the list are summarized and that the outcome is well 
documented (to avoid repetition). The Chair also may choose 
to schedule organized on-line "sessions" with agenda and 
deliverables. These are structured as true meetings, 
conducted over the course of several days (to allow 
participation across the Internet.) Participants are 
expected to allocate time to the meeting, usually in the 
range of 1-2 hours per day of the "meeting". 


Organize, prepare and chair face-to-face & on-line formal sessions 


The Chair should plan and announce sessions well in advance. 
(See section on Session Planning for exact procedures.) 


Communicate results of sessions 


The Chair and/or Secretary must ensure that minutes of a 
session are taken and that an attendance list is circulated. 
See the section on Session Documents for detailed 
procedures. 


Immediately after a session, the WG Chair must immediately 
provide the Area Director with a very short report 
(approximately one paragraph, via email) on the session. 
This is used in an Area Report as presented in the 
Proceedings of each IETF meeting. 


Distribute the work 


Of course each WG will have participants who may not be able 
(or want) to do any work at all. Most of the time the bulk 
of the work is done by a few dedicated participants. It is 
the task of the Chair to motivate enough experts to allow 
for a fair distribution of the workload. 


Document development 
Working groups produce documents and documents need authors. 
The Chair will make sure that authors of WG documents 


incorporate changes as discussed by the WG. See the section 
on Session Documents for details procedures. 
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Document publication 


The Chair and/or Secretary will work with the RFC Editor to 
ensure document conformance with RFC publication 
requirements and to coordinate any editorial changes 
suggested by the RFC Editor. A particular concern is that 
all participants are working from the same version of a 
document at the same time. 


5.2. WG Editor/Secretary 


Taking minutes and editing working group documents often is performed 
by a specifically-designated participant or set of participants. In 

this role, the Editor’s job is to record WG decisions, rather than to 
perform basic specification. 


5.3. WG Facilitator 


When meetings tend to become distracted or divisive, it often is 
helpful to assign the task of "process management" to one 
participant. Their job is to oversee the nature, rather than the 
content, of participant interactions. That is, they attend to the 
style of the discussion and to the schedule of the agenda, rather 
than making direct technical contributions themselves. 


5.4. Design teams 


The majority of the detailed specification effort within a working 
group may be done by self-selecting sub-groups, called design teams, 
with the (implicit or explicit) approval of the working group. The 
team may hold closed sessions for conducting portions of the 
specification effort. In some cases design teams are necessary to 
make forward progress when preparing a document. All work conducted 
by a design team must be available for review by all working group 
participants and the design team must be responsive to the direction 
of the working group’s consensus. 


5.5. Area Consultant 
At the discretion of the AD, a Consultant may be assigned to a 
working group. Consultants are senior participants in the IETF 


community. They have technical background appropriate to the WG and 
experience in Internet architecture and IETF process. 
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5.6. Area Director 


Area Directors are responsible for ensuring that working groups in 
their area produce coherent, coordinated, architecturally consistent 
and timely output as a contribution to the overall results of the 
IETF. This very general description encompasses at the very least 
these detailed tasks related to working groups: 


Area planning 


The Area Director determines activities appropriate to the 
area. This may include initiating working groups directly, 
rather than waiting for proposals from IETF participants. 


Coordination of WGs 


The Area Director coordinates the work done by the various 
WGs within (and sometimes even outside) the relevant area. 


IETF Meeting Schedule 


The Director tries to coordinate sessions in such a way that 
experts can attend the relevant sessions with a minimum of 
overlap and gaps between sessions. (See section on WG 
sessions for details.) 


Reporting 


The Area Director reports to the IETF on progress in the 
area. 


Reviewing 


The Area Director may appoint independent reviewers prior to 
document approval. The Area Director tracks the progress of 

documents from the area through the IESG review process, and 
report back on this to the WG Chair(s). 


Progress tracking 


The Area Director tracks and manages the progress of the 
various WGs with the aid of a regular status report on 
documents and milestones that is generated by the IESG 
Secretary. The Area Director forwards this report to the WG 
chairs. This in turn helps the chairs to manage their WGs. 
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7. Area Directorate 


An area directorate consists of senior members of the technical 
community and are appointed by the Area Director who then tasks them 
with technical oversight and review of specific area activities. An 
Area Director chairs the directorate. At the request of the AD, 
directorate members conduct specification reviews and may be assigned 
as Area Consultants, to provide architectural assistance. 


WORKING GROUP DOCUMENTS 
1. Session documents 


All relevant documents for a session (including the final agenda) 
should be published and available at least two weeks before a session 
starts. 


It is strongly suggested that the WG Chair make sure that an 
anonymous FTP directory be available for the upcoming session. All 
relevant documents (including the final agenda and the minutes of the 
last session) should be placed in this directory. This has the 
advantage that all participants can FTP all files in this directory 
and thus make sure they have all relevant documents. Also, it will be 
helpful to provide electronic mail-based retrieval for those 
documents. 


.2. IETF meeting document archive 


In preparing for an IETF meeting it is helpful to have ready access 
to all documents that are being reviewed. While documents usually are 
placed in the internet-drafts Internet Repository or in the 
respective working group archives or just published in some mail- 
lists, there are just too many things to browse or read through. 
Also, many documents are modified immediately before a meeting. 


The InterNIC Directory and Database Services provides a current- 
ietf-docs archive to enable people to get all documents that are 
relevant for the up-coming IETF meeting. This document database will 
be removed two weeks after the IETF meeting. 


The completeness of this archive depends on the authors and working 
group chairs submitting the documents. Each WG Chair is requested to 
submit the agenda to this archive. 


Structure of the archive: 


On ds.internic.net documents will be stored under the appropriate 
working group name under the appropriate area name in the directory: 
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/pub/current-ietf-docs 
Each area will also have a directory called bof where a document to 
be discussed in a BOF meeting will be placed. At the area level a 
directory called plenary will be created to hold documents or 
presentation material related to a plenary session. Any filename 
conflicts will be resolved by the InterNIC’s administrator and the 
submitter will be informed via electronic mail. Example: 


/pub/current-ietf-docs/app/osids 
/pub/current-ietf-docs/int/sip 


Access via anonymous FTP: 

Anonymous FTP to ds.internic.net and change directory to 
/pub/current-ietf-docs/ 

and browse and get the document of interest. 

Access via gopher: 

Connect to gopher.internic.net and select the menu item: 
4. InterNIC Directory and Database Services (AT&T)/ 

and then the menu item: 
3. Documents to be reviewed at the *** IETF 

One may use the public-access gopher client by: 
telnet gopher.internic.net 

Submission of documents via anonymous FTP: 

FTP to ds.internic.net and login as anonymous. Change directory to: 
/incoming/current-ietf-docs 

Put the document using the following filename convention, 
<area>.<wgname>.<filename> 
plenary.mondayVGs.ps 


app.osids.agenda 
app.osids.internic-talk-VGs.ps 
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Note that the names of areas and working groups are their official 
short-form acronyms, 

Submission of documents via electronic mail: 
Send mail to 
admin@ds.internic.net 


with the following subject line: 


IETF - <area>.<wgname>.<filename> 
e.g. 
IETF - app.osids.agenda 
NOTE: Instead of sending a fresh copy of an already available 


document, you may ask the InterNIC’s administrators to create a link 
to an existing internet-draft/RFC/ID 


NOTE: If you do not remember your area or working group acronym get 
the file /ftp/ietf/lwg-summary.txt from ds.internic.net via anonymous 
ESEP 


6.3. Internet-Drafts (I-D) 


The Internet-Drafts directory is provided to working groups as a 
resource for posting and disseminating early copies of working group 
documents. This repository is replicated at various locations around 
the Internet. It is encouraged that draft documents be posted as soon 
as they become reasonably stable. 


It is stressed here that Internet-Drafts are working documents and 
have no official standards status whatsoever. They may, eventually, 
turn into a standards-track document or they may sink from sight. 
Internet-Drafts are submitted to: 


internet-drafts@cnri.reston.va.us 


The format of an Internet-Draft must be the same as for an RFC [2]. 
Further, an I-D must contain: 


7 Beginning, standard, boilerplate text which is provided by 
the Secretariat; 


- The I-D filename; and 
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= The expiration date for the I-D. 


Complete specification of requirements for an Internet-Draft are 
found in the file: 


lid-guidelines.txt 
in the internet-drafts directory at an Internet Repository site. 
6.4. Request For Comments (RFC) 


The work of an IETF working group usually results in publication of 
one or more documents, as part of the Request For Comments (RFCs) [2] 
series. This series is the archival publication record for the 
Internet community. A document can be written by an individual in a 
working group, by a group as a whole with a designated Editor, or by 
others not involved with the IETF. The designated author need not be 
the group Chair(s). 


NOTE: The RFC series is a publication mechanism only and publication 
does not determine the IETF status of a document. Status is 
determined through separate, explicit status labels assigned by the 
IESG on behalf of the IETF. In other words, the reader is reminded 
that all Internet Standards are published as RFCs, but NOT all RFCs 
specify standards. 


For a description on the various categories of RFCs the reader is 
referred to [1, 4, 5, 6]. 


6.5. Submission of documents 


When a WG decides that a document is ready for publication, the 
following must be done: 


= The version of the relevant document as approved by the WG 
must be in the Internet-Drafts directory; 


= The relevant document must be formatted according to RFC 
rules [2]. 


7 The WG Chair sends email to the relevant Area Director, with 
a copy to the IESG Secretary. The mail should contain the 
reference to the document, and the request that it be 
progressed as an Informational, Experimental, Prototype or 
standards-track (Proposed, Draft or Internet Standard) RFC. 


The IESG Secretary will acknowledge receipt of the email. Unless 
returned to the WG for further development, progressing of the 
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document is then the responsibility of the IESG. After IESG 
approval, responsibility for final disposition is the joint 
responsibility of the RFC Editor and the WG Chair and Editor. 


6.6. Review of documents 


Usually in case of a submission intended as an Informational or 
Experimental RFC minimal review is necessary. However, if the WG or 
the RFC Editor thinks that an extensive review is appropriate, the 
Area Director may be asked to conduct one. This review may either be 
done by the AD and other IESG participants or the IESG may ask for an 
independent review (e.g., by someone not part of the WG in question) 
from the Area Directorate or elsewhere. 


A review will lead to one of three possible conclusions: 
diz The document is accepted as is. 


This fact will be announced by the IESG Secretary to the 
IETF mailing list and to the RFC Editor. Publication is then 
further handled between the RFC Editor and the author(s). 


2% Changes regarding content are suggested to the author(s) /WG. 


Suggestions must be clear and direct, so as to facilitate 
working group and author correction of the specification. 
Once the author(s)/WG have made these changes or have 
explained to the satisfaction of the reviewers why the 
changes are not necessary, the document will be accepted for 
publication as under point 1, above. 


3%. The document is rejected. 


This will need strong and thorough arguments from the 
reviewers. The whole IETF and working group process is 
structured such that this alternative is not likely to arise 
for documents coming from a working group. After all, the 
intentions of the document will already have been described 
in the WG charter, and reviewed at the start of the WG. 


If any individual or group of individuals feels that the review 
treatment has been unfair, there is the opportunity to make a 
procedural complaint. The mechanism for procedural complaints is 
described in the section on Contention and Appeal. 


Before the IESG makes a final decision on a standards-track document, 
the IESG Secretary will issue a "Last Call" to the IETF mailing list. 
This Last Call will announce the intention of the IESG to consider 
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the document, and it will solicit final comments from the IETF within 
a period of two weeks. It is important to note that a Last Call is 
intended as a brief, final check with the Internet community, to make 
sure that no important concerns have been missed or misunderstood. 
The Last Call cannot serve as a more general, in-depth review. 


As SECURITY CONSIDERATIONS 
Security issues are not discussed in this memo. 
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APPENDIX: SAMPLE WORKING GROUP CHARTER 
Multiparty Multimedia Session Control (mmusic) 
Charter 


Chair(s): 
Eve Schooler <schooler@isi.edu> 
Abel Weinrib <abel@bellcore.com> 


Transport Area Director(s) 
Allison Mankin <mankin@cmf.nrl.navy.mil> 


Mailing lists: 
General Discussion:confctrl@isi.edu 
To Subscribe: confctrl-request@isi.edu 
Archive: venera.isi.edu:~ /confctrl/confcrtl.mail 


Description of Working Group: 


The demand for Internet teleconferencing has arrived, yet an 
infrastructure to support this demand is barely in place. 
Multimedia session control, defined as the management and 
coordination of multiple sessions and their multiple users in 
multiple media (e.g., audio, video), is one component of the 
infrastructure. The Multiparty Multimedia Session Control 
Working Group is chartered to design and specify a protocol to 
perform these functions. 


The protocol will provide negotiation for session membership, 


underlying communication topology and media configuration. In 
particular, the protocol will support a user initiating a 
multimedia multiparty session with other users ("calling" other 


users) over the Internet by allowing a teleconferencing 
application on one workstation to explicitly rendezvous with 
teleconferencing applications running on remote workstations. 
Defining a standard protocol will enable session-level 
interoperability between different teleconferencing 
implementations. 


The focus of the working group is to design a session negotiation 
protocol that is tailored to support tightly-controlled 
conferences. The MBONE currently carries primarily loosely- 
controlled sessions, i.e., sessions with little to no interaction 
among members and with no arbitration facility, security, or 
coordination of quality-of-service options for time-critical 
media. Users may learn of available sessions using the "sd" 
utility or other out of band mechanisms (e.g., email). However, 
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there is clearly also a need for tightly-controlled sessions that 
provide mechanisms for directly contacting other users to 
initiate a session and for negotiating conference parameters such 
as membership, media encodings and encryption keys. In addition, 
these sessions should support renegotiation during a session, for 
example to add or delete members or change the media encoding. 

It is possible that the protocol will, in the limiting case, also 
support loosely-controlled sessions. 


The main goal of the working group will be to specify the session 
control protocol for use within teleconferencing software over 
the Internet. The working group will focus on the aspects of the 
session control problem that are well understood, while keeping 
an eye on evolving research issues. Toward this end, the working 
group has made an inventory of existing conferencing systems and 
their session control protocols. The working group will document 
the requirements of the existing prototypes as a basis for the 
protocol development. The working group will iteratively refine 
the protocol based on implementation and operational experience. 


Furthermore, the working group will coordinate with other efforts 
related to multimedia conferencing, such as directory services 
for cataloguing users and conferences, the RTP and RTCP protocols 
developed by the Audio/Video Transport Working Group, resource 
reservation and management at the network level, and schemes for 
multicast address allocation. 


Goals and Milestones: 


May 93 Hold an on-line working group meeting to discuss 
the conference control framework, the relevant 
terminology, a functional taxonomy and how 
different conversational styles place 
requirements on session protocols. 


Jun 93 Submit the Conference Session Control Protocol to 
the IESG for consideration as an Experimental 
Protocol. 

Aug 93 Post an Internet-Draft describing the Session 


Control Requirements. 


Nov 93 Post an Internet-Draft of the Session Control 
Protocol. 
Mar 94 Submit a revised Internet-Draft based on 


implementation experience. 
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